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(54) Charging mechanism for multicasting 

(57) An apparatus (1 70) for calculating a cost of re- 
ceiving multicast data from a multicast session. A mul- 
ticast network (1 05) includes at least one multicast serv- 
ice, each multicast service including at least one multi- 
cast session. The apparatus (170) receives a request 
(117) to establish a connection to the multicast session, 
stores a start time for the connection and an end time 
for the connection and, after termination of the connec- 
tion, calculates the cost of receiving the multicast data. 



The apparatus (170) can receive a subsequent request 
to extend the connection, the subsequent request (1 70) 
specifying a new end time for the connection, and store 
the new end time for the connection. Alternatively, the 
apparatus (170) can receive a subsequent request to 
terminate the connection, the subsequent request spec- 
ifying a new end time that precedes the end time for the 
connection, and store the new end time for the connec- 
tion. 
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Description 

[0001] The present invention relates to a mechanism forcalculating a cost of receiving multicast data from a multicast 
session, particularly, but not exclusively to a method of calculating a cost of receiving multicast data based on either 
5 an elapsed time that a user connects to a multicast session, or a volume of data received at a destination during a 
connection period. 

[0002] A one-to-many or many-to-many Internet Protocol (IP) application involves one or multiple sources sending 
IP messages to multiple receivers. Exemplary applications include the transmission of corporate messages to employ- 
ees, communication of stock quotes to brokers, video and audio conferencing for remote meetings and telecommuting, 

10 and repiicati ng databases and web site information. The IP multicast protocol efficiently supports one -to-many or 
many-to-many applications by allowing a source to send a single copy of a message to any recipient who explicitly 
requests to receive the message. IP mul ticast is more efficient than a point -to-point unicast protocol that requires the 
source to send an individual copy of a message to each requester thereby limiting the number of receivers by the 
bandwidth available to the sender. IP multicast is also more efficient than a broadcast protocol that sends one copy of 

is a message to every node on the network even though many of the nodes may not want the message and the broadcast 
protocol is limited to a single subnet. Furthermore, the IP multicast protocol is applicable not only to wired networks, 
but also wireless networks. For example, in wireless network, link level multicasting allows several terminals to receive 
data sent over a single air interface. 

[0003] IP Multicast is a receiver-based protocol. A receiver subscribes to a multicast session group by sending a 
20 join message to the multicast session group. Since the network infrastructure delivers the traffic to each member of 
the multicast session group, the sender does not need to maintain a list of receivers. The advantage is that only one 
copy of a multicast message passes over any link in the network. In addition, IP Multicast only creates a copy of the 
message when the paths diverge at a router. Thus, I P multicast yields many performance improvements and conserves 
bandwidth throughout the system. 
25 [0004] IP multicast is an extension to the standard IP network -level protocol. RFC 1112, titled "Host Extensions for 
IP Multicasting" and authored by Steve Deering in 1989, describes IP multicasting as "the transmission of an IP dat- 
agram to a 'host group*, a set of zero or more hosts identified by a single IP destination address. IP multicasting delivers 
a multicast datagram to every member of the destination host group with the same 'best -efforts' reliability as regul ar 
unicast IP datagrams. The membership of a host group is dynamic; that is, hosts may join and leave groups at any 
30 time. There is no restriction on the location or number of members in a host group. A host may be a member of more 
than one group at a ti me." In addition, at the application level, a single group address may have multiple data streams 
on different port numbers, on different sockets, in one or more applications. Multiple applications may share a single 
group address on a host. 

[0005] Multicast communications to establish host membership in a multicast group (e.g., a join message) utilize a 
35 standard, such as the Internet Group Management Protocol (IGMP), that supports multicast communication at the 
Open System Interconnection (OSI) data link layer (layer 2). W. Fenner, Internet Group Management Protocol, Version 
2, Request for Comments (RFC) 2236, November, 1997, describe IGMP. 

[0006] In a shared transport media network, encryption takes place at the Open Systems Initiative (OS!) link level 
(level 2) to p revent an unintended user on the same point -to-multipoint link to get the multicast packets. Alternatively, 

40 Internet Protocol security (IPsec) and tunneling can achieve the same result. In addition, in a shared transport network, 
it is difficult for a provider to determine a total charge to associate with a multicast service between a source and a 
user because the total charge comprises a content charge and a delivery charge. The source determines the fee 
associated with the content charge based on the c opyright of the content, the volume of data, or a digital right man- 
agement (DRM) solution. In contrast, the resources consumed during the delivery of the content to a user such as a 

45 content provider dictate the delivery charge. In a wireless network, for example, the resources consumed may include 
wireless radio resources. The content provider is the owner of the multicast data source, however the actual data may 
be obtained from a third party who owns the copyright to the content. 

[0007] The content charge and the delivery charge also differ because the content charge accrues against the user 
and the d elivery charge can accrue against either the content provider or the user, if the delivery charge accrues agai nst 

so the content provider for sending the content ov er a physical network, the accrual of the charge can be on a program 
basis, a data volume basis, or a time basis. Accrual of the delivery charge against the content provider is suitable for 
delivering content such as an advertisement because the content d elivery benefits the content. The disadvantage, 
however, is that accrual of the delivery charge against the content provider requires a service agreement between the 
content provider and the network operator. Thus, when the delivery charge accrues agains t the content provider, it is ■ 

55 not possible to charge for delivery of multicast services originating from any content provider on Internet. If the delivery 
charge accrues against the user for receiving the content over a physical network, it is difficult t o track the volume of 
data that the user receives. Thus, only two types of charging mechanisms are possible, flat rate charging and program 
or file based charging. Flat rate charging requires the user to periodically pay a fixed price for using the servi ce. 
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Program or file based charging requires the user to pay a fee for each request to receive a program or file, in response 
to the payment, the user receives an encryption key that will allow access to the program or file. The program or file 
can include a software application, audio/video file, or graphic image. The encryption scheme can include link level 

encryption or iPsec. , , 

5 [0008] Sophisticated and cost-effective charging mechanisms, such as time based charging and data volume based 
charging, have taken t he place of flat rate charging and program or file based charging mechanisms. A charging 
scheme based on connection time will calculate a fee for a service based on the amount of time that a user connects 
to the service. For example, if a network operator determines that the rate for using a video service is $5.00 per hour, 
a user connecting to the video service to view a movie for thirty -minutes accrues a fee of $2.50. A charging scheme 

io based on the volume of data will calculate a fee for a service base d on the volume of data that a user receives from 
the service. For example, if a network operator determines that the rate for using a video service is $0.25 per Megabyte 
of data received, the fee for a user to use the video service to view a movie consis ting of 25 Megabytes is $6.25. 
[0009] Currently, time based charging and data volume based charging mechanisms are not available for IP multicast 
deployed in a network with shared transport media. Since it is difficult to determine when a user has stopped using a 

15 shared transport media service, it is difficult for network to calculate the connection time or data volume received. For 
example, user may establish a multicast connection through a digital broadcast network, but when the battery in the 
user's terminal loses a charge, the connection is broken without any indication of disjoining the service. Thus, the 
charging will continue even though the multicast service is no longer in use. Furthermore, secu rity is a problem because 
Lhe user has Lhe possibility to disjoin the service, but still receives the data from the shared transport media service. 

20 [001 0] The present invention seeks to provide an improved method of calculating a cost of receiving multicast data 
from a multicast session and/or to provide an improved s ecure billing system for multicast services in a network that 
provides link level multicasting. 

[001 1 ] According to a first aspect of the present invention there is provided a method of calculating a cost of receiving 
multicast data from a multicast session, a m ulticast network including at least one multicast service, each multicast 
25 service including at least one multicast session, comprising receiving a request to establish a connection to the multicast 
session, the request including a start time for the connec tion and an end time for the connection, storing the start time 
for the connection and the end time for the connection and after termination of the connection, calculating the cost of 
receiving the multicast data. The method may further comprise receiving a subsequent request to extend the connec- 
tion, the subsequent request specifying a new end time for the connection and storing the new end time for the con- 

30 nection. The method may further comprise receiving a subsequent request to terminate the connection, the subsequent 
request specifying a new end time that precedes the end time for the connection and storing the new end time for the 
connection. The storing of the start time for the connection and the end time for the connection may be to a database. 
The calculating of the cost may further comprise computing a charge for receiving the multicast data, storing the charge 
and computing the cost by multiplying the charge by a fee for the multicast service associated with t\\e multicast session. 

35 The computing of the charge may further comprise computing an elapsed connection time by subtracting the start time 
for the connection from the end time for the connection. The computing of the charge may further comprise computing 
a volume of data received over the connection from the start time for the connection to the end time for the connection. 
The storing of the charge may be to a database. Time may be divided into evenly spaced time slots, and the start time 
for the connection the end time for the connection ma y only occur at the end of a time slot. The end time for the 

40 connection in the request may be specified as a discrete number of time slots. 

[0012] According to a second aspect of the present invention there is provided a system for calculating a cost of 
receiving multicast data from a multicast session, a multicast network including at least one multicast service, each 
multicast service including at least one multicast session, comprising a memory device and a processor disposed in 
communication with the memory device, the processor configured to receive a request to establish a connection to the 

45 multicast session, the request including a start time for the connection and an end time for the connection, store the 
start time for the connection and the end time fort he connection and after termination of the connection, calculate the 
cost of receiving the multicast data. 

[0013] The processor may be further configured to receive a subsequent request to extend the connection, the sub- 
sequent request specifying a new end time fo r the connection and store the new end time for the connection. The 

50 processor may be further configured to receive a subsequent request to terminate the connection, the subsequent 
request specifying a new end time that precedes the end time for the connect ion; and store the new end time for the 
connection. The processor may store the start time for the connection and the end time for the connection to a database. 
To calculate the cost, the processor may be further configured to compute a charge for receiving the multicast data, 
store the charge and compute the cost by multiplying the charge by a fee for the multicast service associated with the 

55 multicast session. To compute the charge, the processor may be further configured to compute an elapsed connection 
time by subtracting the start time for the connection from the end time for the connection. To compute the charge, the 
processor may be further configured to compute a volume of data received over the connection from the start time for 
the connection t o the end time for the connection. The processor may store the charge to a database. Time may be 
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divided into evenly spaced time slots, and the start time for the connection the end time for the connection may only 
occur at the end of a time slot. The e nd time for the connection in the request may be specified as a discrete number 
of time slots. 

[0014] According to a third aspect of the present invention there is provided a computer program product for calcu- 
5 lating a cost of receiving multicast data from a muiti cast session, a multicast network including at least one multicast 
service, each multicast service including at least one multicast session, comprising a computer readable medium, 
program code in said computer readable medium for receiving a request to est ablish a connection to the multicast 
session, the request including a start time for the connection and an end time for the connection, program code in said 
computer readable medium for storing the start time for the connection and the end time for the connection and after 
10 termination of the connection, program code in said computer readable medium for calculating the cost of receiving 
the multicast data. 

[0015] The computer readable medium may further comprise program code in said computer readable medium for 
re ceiving a subsequent request to extend the connection, the subsequent request specifying a new end time for the 
connection and program code in said computer readable medium for storing the new end time for the connection. The 

15 computer readable medium may further comprise program code in said computer readable medium for receiving a 
subsequent request to terminate the connection, the subsequent request specifying a new end time that precedes the 
end time for the connection and program code in said computer r eadable medium for storing the new end time for the 
connection. The storing of the start time for the connection and the end time for the connection may be to a database. 
The program code in said computer readable medium for calculating the cost may furth er comprise program code in 
20 said computer readable medium for computing a charge for receiving the multicast data, program code in said computer 
readable medium for storing the charge and program code in said computer readable medium for computing the cost 
by multiplying the charge by a fee for the multicast service associated with the multicast session. The program code 
in said computer readable medium for computing the charge may further comprise program code in said computer 
readable medium for computin g an elapsed connection time by subtracting the start time for the connection from the 

25 end time for the connection. The program code in said computer readable medium for computing the charge may 
further comprise program code in said computer readable medium for computing a volume of data received over the 
connection from the start time for the connection to the end time for the connection. The storing of the charge may be 
to a database. Time may be divided into evenly spaced time slots and the start time for the connection the end time 
for the connection may only occur at the end of a time slot. The end time for the connection in the request may be 

30 specified as a discrete number of time slots. 

[0016] According to a fourth aspect of the present invention there is provided a system for calculating a cost of 
receiving multicast data from a multicast session, a multicast network including at least one multicast service, each 
multicast service including at least one multicast session, comprising a collection device co mprising a collection mem- 
ory device and a collection processor disposed in communication with the collection memory device, the collection 

35 processor configured to receive a request to establish a connection to the multicast session, the request including a 
start time for the connection and an end time for the connection, store the start time for the connection and the end 
time for the connection and after termination of the connection, calculate the cost of receiving the multicast data; and 
an interface dev ice comprising an interface memory device and an interface processor disposed in communication 
with the interface memory device, the interface processor configured to configure the collection device; and display 

40 the cost of receiving the multicast data. 

[001 7] The collection processor may be further configured to receive a subsequent request to extend the connection 
that specifies a new end time for the connection and store the new end time for the connection. Thecollection processor 
may be further configured to receive a subsequent request to terminate the connection that specifies a new end time 
for the connection and store the new end time for the connection. The collection processor may store the start time for 

45 the connection and the end time for the connecti on to a database. To calculate the cost, the collection processor may 
be further configured to compute a charge for receiving the multicast data, store the charge and compute the cost by 
multiplying the charge by a fee for the multicast service associated with the multicast session. To compute the charge, 
the collection processor may be further configured to compute an elapsed connection time by subtracting the start time 
for the connection from the end time for the connection. To compute the charge, the collection processor may be further 

so configured to compute a volume of data received over the connection from the start time for the connection to the end 
time for the connection. The collection processor may store the charge to a database. Time may be di vided into evenly 
spaced time slots and the start time for the connection and the end time for the connection may only occur at the end 
of a time slot. The end time for the connection in the request may be specified as a discrete number of time slots. 
[0018] According to a fifth aspect of the present invention there is provided an apparatus for calculating a cost of 

55 receiving multicast data from a multicast session, a multicast network including at least one multicast service, each 
multicast service including at least one multicast session, comprising a computer readable medium, program code in 
said computer readable medium for sending a request to establish a connection to the multicast session, the request 
including a start time for the connection and an end tim e for the connection, program code in said computer readable 
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medium for sending a first subsequent request after the request the first subsequent request including a new end time 
for the connection the new end time being later than the end time and program code in said computer readable medium 
for sending a second subsequent request after the first subsequent request, the second subsequent request including 
an earlier end time for the connection, the earlier end time after the end time and before the new end time. The apparatus 
may further comprise program code in said computer readable medium for determining a request time interval, wherein 
sending the request, sending the first subsequent request, and sending the second subsequent request may only occur 
at a time that is a multiple of the request time interval from the start time. 

[0019] Embodiments of the present invention will now be described, by way of example, with reference to the ac- 
companying drawings in which: 

Figure 1 A is a network diagram that illust rates an operating environment of a secure billing system for multicast 
network services in a network that provides link level multicasting. 

Figure 1B is a network diagram that illustrates the components comprising the secure billing system shown in 
Figure 1A. 

is Figure 1C is a network diagram illustrating an embodiment of the secure billing system shown in Figure 1 A that 

accommodates an indirect connection between user terminal 110 and multicast data network 105. 
Figure 1D is a reiwor< diagram that illustrate s the components comprising the secure billing system shown in 
Figure 1C. 

Figure 1E is * network digram illustrating an embodiment of the secure billing system shown in Figure 1 A that 
20 distributes the security fund on to uase station 140 and the charging function to charging server 150. 

Figure 1F is a retworN diagram that illustrates the components comprising the secure billing system shown in 
Figure 1E. 

Figure 1G is a network diagram that illustrates the components comprising the secure billing system shown in 
Figure 1E. 

25 Figures 2A and 2B illustrate a method of operation for the secure billing system shown in Figure 1 B. 

Figures 2C and 2D illustrate a method of operation for the secure billing system shown in Figure 1G. 

Figure 3A is an exemplary timeline fo r a charging scheme based on connection time that illustrates an explicit 

disjoin. 

Figure 3B is an exemplary timeline for a charging scheme based on connection time that illustrates an implicit 
30 disjoin. 

Figure 3C is an exemplary timeline for a charging sch erne based on slotted connection time that illustrates an 
explicit disjoin. 

Figure 3D is an exemplary timeline for a charging scheme based on slotted connection time that illustrates an 
implicit disjoin. 

35 Figure 4A is an exemplary timeline for a charging sch erne based on data volume that illustrates an explicit disjoin. 

Figure 4B is an exemplary timeline for a charging scheme based on data volume that illustrates an implicit disjoin . 

[0020] Figure 1 A is a network diagram that illustrates an operating environment of a secure billing system for multicast 
network services in a network that provides link level multicasting. Internet 100 and multicast data network 105, as 

40 shown in Figure 1 A, are public communication networks that support multicast delivery of data packet s, in general, 
and multicast delivery of Internet protocol (IP) data packets, in particular. The invention disclosed herein contemplates 
network architectures comparable to Internet 100 and multicast data network 105 such as a cellular network, a satellite 
network, a digital video broadcasting (DVB) network, or a private network architecture. Private network architectures 
include a local area network, a personal area network such as a Bluetooth network, an intranet, or an extranet. An 

45 intranet is a priva te communication network that provides an organization, such as a corporation, with a secure means 
for trusted members of the organization to access the resources on the organization's network. In contrast, an extranet 
is a private communication network t hat provides an organization, such as a corporation, with a secure means for the 
organization to authorize non - members of the organization to access certain resources on the organization's network. 
The invention disclosed herein also contemplates network protocols such as Ethernet, Token Ring, and proprietary 

so network protocols comparable to the Internet protocol. 

[0021] As shown in Figure 1 A, user terminal 110 includes an interface module that connects a user to the secure 
billing system for multicast network ser vices. In one embodiment, user terminal 110 is a general-purpose computer. 
User terminal 110 also includes a communication module to communicate with devices on multicast data network 105 
to receive multicast session data from devices on Internet 100. A user operates user terminal 1 10 to receive multicast 

55 content 195 by sending join request 117 to last hop router 120. After receiving join request 117, last hop router 120 
attaches to the multicast tree using any existing multicast routing protocol. In o ne embodiment, last hop router 120 
attaches to the multicast tree via border gateway 180. Last hop router 120 and border gateway 180 perform routing 
functions for multicast data network 105. Last hop router 120 is the last routing entity that handles dat a passing from 
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multicast capable data network 105 to user terminal 110. For example, last hop router 120 may be a general-purpose 
router in a wireless local area network (WLAN) or a Serving General Packet Radio Service (GPRS) Support Node 
(SGSN) in a GPRS or Universal Mobile Telecommunications System (UMTS) network. Border gateway 180 is the 
routing entity that provides the interface between multicast data network 105 and an external network such as Internet 

5 100. In response to join request 117, user terminal 110 receives decryption key 118 from multicast data network 105. 
In one embodiment, last hop router 120 is responsible for sending decryption key 1 1 8 to user terminal 1 1 0 and encrypts 
the data sent by multicast server 190 prior to forwarding the data to user terminal 1 10. In addition to data routing, last 
hop router 120 monitors multicast communication messages that user terminal 110sends and receives, stores charging 
data related to a subscription request, and forwards the charging data to billing server 170, a general-purpose server 

10 computer. Billing server 170 converts the charging data into billing data, stores the billing data, and notifies the user 
of the total charge for subscribing to multicast content 195. 

[0022] In another embodiment of the secu re billing system shown in Figure 1A, multicast data network 105 is a 
visiting wireless network for user terminal 110. Since billing server 170 is not in the home network for user terminal 
110, billing server 1 70 forwards any billing data fo r user terminal 1 1 0 to the home billing server (not shown) in the home 
is network (not shown) for user terminal 1 1 0. The home network (not shown) will connect to either multicast data network 
105 or Internet 100 via a connecting border gateway (not shown). 

[0023] In another embodiment of the secure billing system shown in Figure 1 A, the functions comprising collection 
of the charging data that last hop router 120 performs are distributed throughout multicast data network 105 to reduce 
the processing load imposed upon last hop router 1 20. For example, if the charging data includes connection time data 
20 and throughput volume data, last hop router 120 can be responsible for collecting the time data and an intermediate 
router (not shown) along the multicast tree in multicast data netw ork 105 can be responsible for collecting the through- 
put volume data. 

[0024] In another embodiment of the secure billing system shown in Figure 1 A, the operator of multicast data network 
105 provides the multicast service. Thus, multicast server 190 is located in multicast data network 105. 

25 [0025] In another embodiment of the secure billing system shown in Figure 1 A, billing server 170 is located in another 
physical network such as Internet 100 and connects with multicast data network 105 via a Virtual Private Network 
(VPN). Alternatively, last hop router 120 can also include the functionality performed by billing server 170. Thus, last 
hop router 120 will include a module that converts charging data into billing data, stores the billing data temporarily 
and periodically forwards the billing data to a billing center. 

30 [0026] Figure 1B is a network diagram that illustrates the components comprising the secure billing system shown 
in Figure 1A. User terminal 110 comprises service discovery 111, multicast session management 112, and multicast 
security client 113. Service discovery 111 enables the terminal to discover multicast sessions by providing the user 
with a list of available multicast sessions and the cost associated with each session. Multicast session management 
112 is responsible for establishing a multicast session, maintaining the session communication, and disconnecting the 

35 session when the communication is complete. Multicast security client 113 manages the security associated with re- 
ceiving multicast data from a n etwork connection. For example, multicast security client 113 periodically receives 
decryption key 118 for decrypting the multicast session data. 

[0027] Referring again to Figure 1B, last hop router 120 is the last routing entity through which IP data destined for 
user terminal 110 passes. Last hop router 120 comprises routing function 121 , group membership management 122, 

40 multicast security unit 123, multicast charging unit 124, data volume meter 125, and charging database 126. Routing 
function 121 performs traditional network routing and provides supportforthe IP multicast protocol. Group membership 
management 122 maintains the group membership information for every terminal on the same multicast link and is 
responsible for determining the join status of ea ch terminal. Multicast security unit 123 is responsible for sending 
decryption key 118 to user terminal 110. Optionally, multicast security unit 123 may encrypt the multicast data from 

45 multicast server 190 before it is sent to user terminal 110. Multicast security unit 123 sends decryption key 118 when 
the user initially joins a multicast session. Multicast security unit 123 updates decryption key 118 either when another 
multicast user terminates the session or at discrete time intervals. Multicast security unit 143 communicates decryption 
key 118 to multicast security client 113 either by a direct connection, via routing function 121 , or via routing function 
121 and group membership management 122. Multicast charging unit 124 maintains information rel ated to multicast 

50 session charges for user terminal 110. Multicast charging unit 124 creates a charging entry in charging database 126 
when user terminal 110 joins a multicast session. Multicast charging unit 124 updates the charging entry when user 
terminal 110 updates the join status or terminates the session. When user terminal 110 terminates the session, multicast 
charging unit 124 retrieves the relevant session charge information from charging database 126 and forwards the 
information to billing server 170. Data volume meter 125 measures, for a multicast session, the number of bytes or 

55 data volume transmitted to user terminal 110. Charging database 126 stores information related to multicast session 
charges. The implementation of charging database 126 contemplates a fiat-file architecture, relational database man- 
agement system design, object-oriented database design, or the equivalent. 

[0028] Referring again to Figure 1B f billing server 170 is a general-purpose server computer that includes a module 
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to convert charging information such as connection time or data volume into billing data including the cost to receive 
the mult cast session data. Billing server 170 comprises billing unit 1 71 and billing database 172. Billing unit 171 con- 
verts the information related to multicast session charges into billing information. Billing database 172 stores the billing 
information. The implementation of billing database 172 contemplates a fiat-file architecture, relational database man- 

5 agement system design, object -oriented database design, or the equivalent. 

[0029] Figure 1C is a network diagram illustrating an embodiment of the secure billing system shown in Figure 1 A 
that accommodates an indirect connection between user terminal 110 and multicast data network 105. Internet 100 
and multicast data network 105 perform the same functions as described above in the discussion of Figure 1 A. Bi- 
directional network 106 is a data network such as a General Packet Radio Service (GPRS) network that supports 

10 uplink connectivity and provides an interface between user terminal 1 1 0 and multicast data network 1 05. Uni-directional 
network 107 is a data network such as a DVB terrestrial (DVB -T) network that transmits multicast data to entities such 
as user terminal 110. The invention disclosed herein contemplates network architectures comparable to bi -directional 
network 106 and uni-directional network 107 such as a cellular network, a satellite network, a DVB network, or a private 
network architecture. 

is [0030] As shown in Figure 1 C, user terminal 1 1 0 includes an interface module that connects a user to the secure 
billing system for multicast network services. In one embodiment, user terminal 1 1 0 is a mobile device such as a cellular 
telephone. User terminal 1 1 0 also includes a communication module to receive multicast data transmitted by multicast 
serving node 130. A user operates user terminal 110 to receive multicast content 195 by sending join request 117 to 
multicast serving node 130 via bi-directional network 106. After receiving join reque st 117, multicast serving node 130 

20 attaches to the multicast tree using any existing multicast routing protocol. In one embodiment, multicast serving node 
130 attaches to the multicast tree via border gateway 180. Multicast serving node 130 and border gateway 1 80 perform 
routing functions for multicast data network 105. Multicast serving node 130 forwards the multicast data from multicast 
data network 105 to user terminal 110 via either bi-directional network 106 or uni-directional network 107. Border 
gateway 180 is the routing entity that provides the interface between multicast data network 105 and an external 

25 network such as Internet 100. In response to join request 117, user terminal 110 receives decryption key 118 from 
multicast serving node 130 vi a bi-directional network 106. In one embodiment, multicast serving node 130 is respon- 
sible for sending decryption key 118 to user terminal 110 and encrypts the data sent by multicast server 190 prior to 
forwarding the data to user terminal 110. Multicast serving node 130 also forwards the multicast data comprising mul- 
ticast content 195 to user terminal 110 via uni-directional network 107. In addition to data routing, multicast serving 

30 node 130 monitors multicast communication messages that user terminal 110 sends and receives, stores charging 
data related to a subscription request, and forwards the charging data to billing server 170, a general-purpose server 
computer. Billing server 170 converts the charging data into billing data, stores the billing data, and notifies the user 
of the total charge for subscribing to multicast content 195. 

[0031] An example of the embodiment shown in Figure 1C includes delivering IP data from an Internet Service 
35 Provider (ISP) network owned by operator A via a DVB terrestrial (D VB-T) network owned by operator B to the mobile 
terminal operated by a user. A service agreement between the user and operator A obligates the user to pay a fee for 
receiving multicast data that operator A delivers. Also, an agreement between operator A and operator B obligates 
operator A to pay a fee for sending data over the DVB -T network owned by operator B. To subscribe to a multicast 
session the user sends join request 117 to multicast serving node 130 via the data network owned by operator C. Mul 
40 ticast serving node 130 delivers multicast session data to the mobile terminal via the DVB-T network owned by operator 
B, monitors multicast communication messages, stores charging data related to the subscription request, and forwards 
the charging data to billing server 170. 

[0032] Figure 1D is a network diagram that illustrates the components comprising the secure billing system shown 
in Figure 1C. Except for the differences described below, the function and structure of the components shown in Figure 
45 id are identical to the components shown in Figure 1B. Multicast serving node 130 performs the functions described 
for last hop router 120 in the discussion of Figure 1 B. In Figure 1D, routing function 131 and multicast security unit 133 
do not communicate with user terminal 110 directly, but via either bi -directional network 106 or uni-directional network 
107. Similarly, multicast session management 112 does not communicate with multicast serving node 130 directly, but 
via bi -directional network 106. 

so [0033] Figure 1E is a network diagram illustrating an embodiment of the secure billing system shown in Figure 1 A 
that distributes the security function to base station 140 and the charging function to charging server 150. As shown 
in Figure 1E, user terminal 110 is a mobile device that communicates with wireless network 108 via base station 140. 
In one embodiment, base station 140 is the base station subsystem in a GPRS network. A user operates user terminal 
110 to receive multicast content 195 by sending join request 117 to base station 140. After receiving join request 117, 

55 base station 140 attaches to the multicast tree using any existing multicast routing protocol. In one embodiment, base 
station 140 attaches to the multicast tree via last hop router 120 and border gateway 180. Last hop router 120 and 
border gateway 180 perform routing functions for wireless network 108. In response to join request 117, user terminal 
1 10 receives decryption key 1 1 8 from base station 140. In one embodiment, base station 1 40 is responsible for sending 
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decryption key 118 to user terminal 1 10 and encrypts the data sent by multicast server 190 prior to forwarding the data 
to user terminal 110. In addition to data routing, the connection between last hop router 120 and base station 140 allow 
last hop router 120 to monitor multicast communication messages that user terminal 110 sends to and receives from 
base station 140. Last hop router 120 also transfers charging data related to a subscription request to charging server 
150. In one embodiment, charging server 150 stores the charging data and periodically forwards the data via a direct 
connection to billing server 1 70. In another embodiment, charging server 1 50 stores the charging data and periodically 
forwards the data to billing server 170 via a connection between last hop router 120 and billing server 170. Charging 
server 150 and billing server 170 are general-purpose server computers. 

[0034] Figure 1F is a network diagram that illustrates the components comprising the secure billing system shown 
in Figure 1 E. Except for the differences described below, the function and structure of the components shown in Figure 
1F are identical to the components shown in Figure 1B. Figure 1F distributes the components of last hop router 120, 
as shown in Figure 1B, among last hop router 120, base station 140, and charging server 150. Last hop router 120 
comprises routing function 121 , group membership management 122, and data volume meter 125. Base station 140 
comprises multicast security unit 123, the communication interface between multicast security unit 123 and routing 
function 1 21 . and the communication interface between multicast security unit 1 23 and group membership management 
122. Charging server 150 comprises multicast charging unit 124, charging database 126, the communication interface 
between multicast charging unit 124 and group membership management 122, and the communication interface be- 
tween multicast cnargmg unit 1 24 and data volume meter 125. In one embodiment, billing server 170 comp rises billing 
unit 171 and billng database 172 nnd charging server 150 further comprises a communication interface between 
charging unit 124 nnd billing unit 171. 

[0035] Figure 1G is a network diagram that illustrates the components comprising the secure billing system shown 
in Figure 1E. Except for the differences described below, the function and structure of the components shown in Figure 
1 G are identical to the components shown in Figure 1 F. Figure 1G illustrates a distributed architecture for group mem- 
bers hip management 122 shown in Figure 1 F. Last hop router 120, as shown in Figure 1 G, comprises routing function 
121, data volume meter 125, and network layer group membership management 128. Base station 140, as shown in 
Figure 1G, comprises multicast secunty unit 123, link layer group membership management 127, the communication 
interface between multicast secunty unit 123 and routing function 121, and the communication interface between link 
layer group membership management 127 and network layer group membership management 128. Charging server 
150, as shown in Figure 1G, comprises multicast charging unit 124, charging database 126, the communication inter- 
face between multicast charging unit 124 and network layer group membership management 1 28, and the communi- 
cation interface between multicast charging unit 124 and data volume meter 125. Link layer group membership man- 
agement 127 maintains the information of the join status of user terminal 110 within the cell and provides that information 
to multicast charging unit 124. Whenever there are any multicast receivers within the cell, link layer group membership 
management 127 informs network layer group membership management 128 to join the multicast tree. Network layer 
group membership management 128 is responsible for keeping track of which base station needs multicast data and 
routes the multicast data to the appropriate base station. 

[0036] Figures 2A and 2B illustrate a method of operation for the secure billing system shown in Figure 1 B. Referring 
to Figures 1 A and 2A, the method begins at step 202 with multicast server 190 announcing the available multicast 
sessions to user terminal 1 1 0 via multicast data network 1 05. At step 204, service discovery 11 1 discovers the multicast 
sessions that are available. Service discovery 111 provides an operator of user terminal 110 with a list of available 
multicast sessions and the relevant information for each session. The relevant information includes the starting time 
and cost associated with a multicast session. The operator seiects a multicast session from the list. In response to the 
operator's selection, user terminal 110 activates the selected multicast session. In one embodiment, the activation of 
the multicast session occurs immediately. In another embodiment, the activation occurs at a predetermined time such 
as before the start of the multicast session. At step 206, multicast session management 112 sends join request 117 
for the selected multicast session to group membership management 122. Group membership management 122 re- 
ceives join request 117 at step 208 and records the join status of the user terminal at step 212. Group membership 
management 122 forwards the joined status information to multicast charging unit 124 and multicast security unit 123. 
Multicast charging unit 124 uses the joined status information to create a charging entry in charging database 146 at 
step 214. Multicast security unit 123 uses the joined status information to send a decryption key to user terminal 110 
at step 216 which multicast security client 113 receives at step 218 before receiving multicast session data at step 
220. In one embodiment, multicast security unit 123 encrypts the message prior to sending the decryption key and 
multicast security client 113 decrypts the message after receiving the decryption key. After receiving join request 117 
at step 208, group membership management 1 22 also attaches to the multicast tree using any multicast routing protocol 
at step 21 0. In one embodiment, group membership manageme nt 122 applies authentication and authorization pro- 
cedures before attaching to the multicast tree. At s«?~ 222, multicast server 190 sends multicast session data to mul- 
ticast security unit 1 23. The multicast session data is encrypted by multicast securit y unit 1 23 at step 224 and decrypted 
by multicast security client 113 at step 226 before receiving multicast session data at step 220. 
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[0037] At step 228, Figure 2A illustrates user terminal 110 updating the join status, for example, to extend the duration 
of the multicast session connection. Multicast session management 112 resends the join request to group membership 
management 122. Group membership management 122 updates the join status for user terminal 110 at step 230 and 
notifies multicast security unit 123 to send an updated decryption key at step 216. Multicast session management 112 
is responsible for sending an updated join request to last hop router 120 on an on-going basis. As long as the user is 
receiving the session, multicast session management 1 1 3 must update the join status for the terminal before it expires. 
Whenever the join status is updated, group membership management 122 also forwards the status to multicast charging 
unit 124 to update the charging entry at step 232. After updating the j oin status for user terminal 110 at step 230, 
group membership management 122 notifies multicast charging unit 124 to update the charging entry in charging 
database 126 at step 232. 

[0038] At step 234, Figure 2B illustrates user terminal 110 terminating the multicast session, either explicitly or im- 
plicitly by sending a disjoin message to last hop router 140. Group membership management 122 receives the disjoin 
message and. at step 236, notifies multicast charging unit 124 to close the charging entry for user te rminal 110 in 
charging database 126. Multicast charging unit 124 forwards the charging data to billing server 170 at step 238. Billing 
server 170 converts the charging data to billing data, at step 240, and sends the billing data to the user at step 242. If 
a data volume based charging mechanism is used, in order to generate and update the charging entry, data volume 
mete 125 forwards to multicast charging unit 1 24 the volume of data delivered to user terminal 1 1 0. At step 244, group 
mcmoership management 1 22 determines whether any receivers of the multicast data have an active join status. If no 
receivers have an aclive join status, at step 246, group membership management 122 detaches user terminal 110 
from the multicast tree, if there is at least o ne receiver with an active status, group membership management 122 
proceeds to steps 230 and 216 where the terminal status is updated and multicast security unit 1 23 is notified to send 
an updated decryption key to multicast security client 113. 

[0039] Figures 2C and 2D illustrate a method of operation for the secure billing system shown in Figure 1 G. Referring 
to Figures 1E and 2C, the method begins at step 202 with multicast server 190 announcing the available multicast 
sessions to user terminal 110 via wirelesss network 108. At step 204, service discovery 111 discovers the multicast 
sessions that are available. Service discovery 111 provides an operator of user terminal 110 with a list of available 
multicast sessions and the relevant information for each sess ion. The relevant information includes the starting time 
and cost associated with a multicast session. The operator selects a multicast session from the list. In response to the 
operator's selection, user terminal 110 activates the selected multicast se ssion. In one embodiment, the activation of 
the multicast session occurs immediately. In another embodiment, the activation occurs at a predetermined time such 
as before the start of the multicast session. At step 206, multicast session management 112 sends join request 117 
for the selected multicast session to link layer group membership management 127. Link layer group membership 
management 127 receives join request 117 at step 208 and records the join status of the user terminal at step 212. 
Link layer group membership management 127 forwards the joined status information to multicast charging unit 124 
and multicast security unit 123. Multicast charging unit 124 uses the joined status information to create a chargtng 
entry in charging database 146 at step 214. Multicast security unit 123 uses the joined status information to send a 
decryption key to user terminal 110 at step 216 which multicast security client 113 receives at step 218 before receiving 
multicast session data at step 220. In one embodiment, multicast security unit 123 encrypts the message prior to 
sending the decryption key and multicast security client 113 decrypts the message after receiving the decryption key. 
After receiving join request 117 at step 208, link layer group membership management 127 also notifies network layer 
group membership management 128 to attach to the multicast tree using any multicast routing protocol at step 210. 
In one embodiment, link layer group membership management 127 applies authentication and author ization proce- 
dures before attaching to the multicast tree. At step 222, multicast server 1 90 sends multicast session data to multicast 
security unit 123. The multicast session data is encrypted by multicast security unit 123 at step 224 and decrypted by 
multicast security client 113 at step 226 before receiving multicast session data at step 220. 

[0040] At step 228. Figure 2C illustrates user terminal 110 updating the join status, for example, to extend the duration 
of the multicast session connection. Multicas t session management 112 resends the join request to link layer group 
membership management 1 27. Link layer group membership management 1 27 updates the join status for user terminal 
110 at step 230 and notifies multicast security unit 123 to send an updated decryption key at step 216. Multicast session 
management 112 is responsible for sending an updated join request to last hop router 120 on an on-going basis. As 
long as the user is receiving the session, multicast session management 1 1 3 must update the join status for the terminal 
before it expires. Whenever the join status is updated, link layer group membership management 127 also forwards 
the status to multicast charging unit 124 to update the charging entry at step 232. After updating the join status for user 
terminal 1 10 at step 230, link layer group membership management 127 notifies multicast charging unit 124 to update 
the charging entry in charging database 126 at step 232. 

[0041] At step 234, Figure 2D illustrates user terminal 110 terminating the multicast session, either explicitly or im- 
plicitly, by sending a disjoin message to last hop router 140. Link layer group membership management 127 receives 
the disjoin message and, at step 236. notifies multicast charging unit 124 to close the charging en try for user terminal 
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110 in charging database 126. Multicast charging unit 124 forwards the charging data to billing server 170 at step 238. 
Billing server 170 converts the charging data to billing data, at step 240, and sends the billing data to the user at step 
242. If a data volume based charging mechanism is used, in order to generate and update the charging entry, data 
volume meter 125 forwards to multicast charging unit 124 the volume of data delivered to user terminal 110. At step 

5 244, link layer group membership management 127 determines whether any receivers of the multicast data have an 
active join status. If no receivers have an active join status, link layer group membership management 127 notifies 
network layer group membership management 128, at step 246, to detach user terminal 110 from the multicast tree. 
If there is at least one receiver with an active status, link layer group membership management 127 proceeds to steps 
230 and 216 where the terminal status is updated and multicast security unit 123 is notified to send an updated de- 

10 cryption key to multicast security client 113. 

Connection Time Charging 

[0042] A charging scheme based on connection time calculates a fee for a service from the elapsed time that a user 
15 connects to the service. Fo r example, if a network operator determines that the rate for using a video service is $5.00 
per hour, a user connecting to the video service to view a movie for thirty-minutes accrues a fee of $2.50. In a multicast 
network, a charging scheme based on connection time is most beneficial when an average multicast session has a 
fixed bandwidth. Determination of the connection time involves storing the time that the user terminates the multicast 
session connection, storing the time that the user initiates the multicast session connection, and calculating the differ- 
20 ence between these times. Since a multicast session is dynamic, the challenge is to determine when the initiation and 
termination of the connection occurs. 

[0043] The packets that comprise a multicast sess ion are encrypted. Thus, a user cannot receive the multicast 
session without explicitly requesting to join a multicast group and receiving a decryption key. Referring to Figure 1B, 
service discovery 171 receives all the available multicast sessions from last hop router 140. When user terminal 170 

25 selects and activates a multicast session, multicast session management 172 explicitly requests to join a multicast 
group by sending join message 160 to group membership management 142. In response, group membership man- 
agement 142 notifies multicast charging unit 144 and multicast security unit 143 that user terminal 170 agrees to pay 
a fee based on the connection time to the multicast service. Multicast charging unit 144 creates a charging entry for 
user termi nal 170 and multicast content 110. Multicast security client 173 receives decryption key 165 from multicast 

30 security unit 143 that will decrypt the multicast session packet data. Group membership management 142 receives 
every join message sent by a user of the multicast service associated with a multicast group. A validated or authenti- 
cated join message activates the "joined" status for the user who sent the join message. Multicast charging unit 144 
creates and maintains an entry in charging database 146 for each validated join message. The entry in charging da- 
tabase 146 comprises user identification data, session identification data, a cumulative connection time, and an exc : - 

35 ration time for the "joined" status. 

[0044] The join message sent by the user identifi es the requested multicast session, the requested start time for 
the charging, and the requested stop time for the charging. The join message obligates the user to pay the charges 
that accrue from the start time to the end time. When the user has "joined" status, the multicast network is responsible 
for updating the user's "decryption key u whenever host membership in the multicast group changes. For a discussion 

40 of several methods for delivery of the decryption key see "Secure Group Communication using K ey Graphs", IEEE/ 
ACM Transactions on Networking, February 2000. 

[0045] The stop time specified in the join message is the initial stop time for the user's multicast session. The user 
can extend the stop time by sending a second join message to specify a later stop time. The stop time can only be 
extended if group membership management 142 receives the second join message prior to the initial stop time. If the 

45 second join message arrives after the first join status expires, the user will be disconnecting with th e multicast session 
first as a result of the expired join status. When the second join message arrives, it will act as a new join message to 
connect user terminal 110 to the multicast session. Following the receipt of a second or subsequent join message, 
multicast charging unit 144 updates the entry for the user and multicast session in charging database 146 and notifies 
other group members of a membership change. 

so [0046] In one embodiment, the interval between the start time and the stop time in each join message can be deter- 
mined based on the configuration set by either the user or network operator. In another embodiment, the interval 
between the start time and the stop time can be calculated according to an environmental characteristic including the 
velocity o f the terminal, the strength of the reception signal, and the quality of the reception signal. 
[0047] Termination of the multicast session can happen either explicitly or implicitly. Explicit termination of the mul- 

55 ticast session occurs when the user sends a disj oin message that specifies a stop time earlier than the pending stop 
time. A disjoin message is only effective, however, if group membership management 142 receives the disjoin message 
prior to the pending stop time. Following receipt of a disjoin messag e, multicast charging unit 144 updates and closes 
the entry in charging database 146 and forwards the charging data to billing unit 151 for conversion into billing data 
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and storage in billing database 152. If the forwarding of the charging data is successful, multicast charging unit 144 
deletes the entry in charging database 146 and. if the second join message arrives after the first jo:n status expires, 
multicast security unit 143 updates decryption key 165 for other group members of the same multicast se ss.on. Implicit 
termination of the multicast session occurs when the user* s "joined" status expires before the user sends a subsequent 
join message to extend the stop time. An implicit termination may occur, for example, when the battery in the user's te 
rminal loses power or some other reason that causes terminal to loose the network connection. Accounting for implicit 
termination of a multicast session ensures that an excessive charge does not accrue for the user. 
[00481 When the user status changes state from "joined" to "disjoined", multicast charging unit 1 44 calculates the 
total connection time. The billing related information such as user identification data, session identification data, and 
connection time is transferred from multicast charging unit 144 to billing server 150. Then, billing unity 151 converts 
the charging data into billing data and stores the billing data in billing database 152. Alternatively, multicast charging 
unit 144 periodically transfers billing data to billing server 150. 

UNRESTRICTED CONNECTION TIME 

1-00491 Fiqures 3A and 3B are exemplary timelines for a charging scheme based on connection time that allows a 
user to join or leave a multicast session at any time. Referring to Figures 1 B and 3A, if user terminal 170 explicitly 
requests termination of the multicast session connection, determination of the connection time comprises: 

1 Userterminal 170 sending a join message to group membership management 142 attimef xo . If thejoin message 
takes the form join(p, f s1 , %,), the user is requesting to join multicast session p, start the connection time charging 
at time f s1 , and end the connection time charging at time % v If the user wants to start the connection time charging 

immediately, f s1 is set equal to null. , t ^ 

2. Multicast security client 173 receiving decryption key 165 from multicast security un.t 143 before time f s1 . De- 
cryption key 165 functions to decrypt the packet data comprising multicast session p. 

3 At time f s1 multicast charging unit 144 adds an entry to charging database 146 to track connection time charges 
for user terminal 170 using multicast session p. In one embodiment, the entry to charging database 1 46 appears 
as follows. 



User 
Identification 


Session Identification 


Connection 
Time 


Expiration Time of "Joined" 
Status 


21323421 


finnkino 457286529 1453 
172.10.20.212 


(%i - fsi) 





If the user sets f s1 in the join message equal to null to indicate that the connection time charging will start imme- 
diately fv 0 will replace f s1 in the charging table because the join message was sent at time f xo . 
4. From time f s1 until time f E1 , the multicast network is responsible for updating decryption key 1 65 for userterminal 
170 whenever host membership in the multicast group changes. 

5 At time / X1 where f x1 < f E1 , user terminal 170 extends the s top time by sending a second join message to 
specify a later stop time. If the second join message takes the form join( p, f E1 , f E2 ), the user is requesting to extend 
the end time for the connection to multicast session p from time f E1 to time % 2 . 

6 At time f E1 multicast charging unit 144 updates the entry in charging database 146 to track connection time 
charges for user terminal 170 using multicast session p. In one embodiment, the entry to charging database 146 
appears as follows: 



User 
identification 


Session Identification 


Connection Time 


Expiration Time of "Joined" 
Status 


21323421 


finnkino 457286529 1453 
172.10.20.212 


(%i -'si) + (te>-fei) 


%2 



7. From time f E1 until time f E2 , the multicast network is responsible for updating the "decryption key" for userterminal 
170 whenever host membership in the multicast group changes. 

8 At time ty* where f X2 < f E2 , user terminal 170 sends a disjoin message that specifies a stop time earlier than 
the pending stop time, fe. If the disjoin message takes the for m leave(p, % 3 ), user terminal 170 is requesting to 
leave multicast session p at time % 3 . If user terminal 170 wants to leave multicast session p immediately, f E3 is 
set equal to null. Multicast charging unit 144 updates the entry in charging database 146 to track connection time 
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charges for user terminal 170 using multicast session p. In one embodiment, the entry to charging database 14S 
appears as follows: 



User 
Identification 


Session Identification 


Connection Time 


Expiration Time of "Joined" 
Status 


21323421 


finnkino 457286529 1453 
172.10.20.212 


(<E1-<Si) + ('E2- 'Effe- 
te!) 


<E3 



If the user sets % 3 in the disjoin message equal to null to indicate that user terminal 1 70 wants to leave multicast 
session p immediately, f X2 will replace % 3 in the charging table because the join message was sent at time f X2 . 
9. At time % 3 , collection of connection time charges for user terminal 170 stops. The multicast network is responsible 
for updating the "decryption key" for the other group members because user terminal 170 disjoined the multicast 
group. Since the collection of connection time charges has stopped, multicast charging unit 144 closes the entry 
in charging database 146 for user terminal 170 using multicast session p, communicates the charging data to 
billing unit 151 for storage in billing database 152, and deletes the entry In charging database 146. 

[0050] Referring to Figures 1 B and 3B, if termination of the multicast session connection is implied from the passage 
of time, steps 1 through 7 are i dentical to steps 1 through 7 from the discussion of Figure 3A and determination of the 
connection time comprises: 

1 . User terminal 1 70 sending a join message to group membership management 1 42 at time f xo . If the join message 
takes the form join(p, f s1 , f E1 ), the user is requesting to join multicast session p, start the connection time charging 
at time t sv and end the connection time charging at time f E1 . If the user wants to start the connection time charging 
immediately, r s1 is set equal to null. 

2. Multicast security client 173 receiving decryption key 165 from multicast security unit 143 before time f s1 . De- 
cryption key 165 functions to decrypt the packet data comprising multicast session p. 

3. At time f s1 , multicast charging unit 144 adds an entry to charging database 146 to track connection time charges 
for user terminal 170 using multicast session p. In one embodiment, the entry to charging database 146 appears 
as follows: 



User 
Identification 


Session Identification 


Connection 
Time 


Expiration Time of "Joined" 
Status 


21323421 


finnkino 457286529 1453 
172.10.20.212 


(%1 * fel> 


%1 



If the user sets f s1 in the join message equal to null to indicate that the connection time charging will start imme- 
diately, f xo will replace f si in the charging table because th e join message was sent at time r xo . 

4. From time % 1 until time % 1t the multicast network is responsible for updating decryption key165 for userterminal 
170 whenever host membership in the multicast group changes. 

5. At time f x1 , where f x1 < % v userterminal 170 extends the stop time by sending a second join message to specify 
a later stop time. If the second join message takes the form join( p, f E1 , fa), the user is requesting to extend the 
end time for the connection to multicast session pfrom time f E1 to time f E2 . 

6. At time f E1 , multicast charging unit 144 updates the entry in charging database 146 to track connection time 
charges for user terminal 170 using multicast session p. In one embodiment, the entry to charging database 146 
appears as follows: 



User 
Identification 


Session Identification 


Connection Time 


Expiration Time of "Joined" 
Status 


21323421 


finnkino 457286529 1453 
172.10.20.212 


(%1 -'si) + (%2- fel) 


'E2 



7. From time f E1 until time fa, the multicast network is responsible for updating t he "decryption key" for user 
terminal 170 whenever host membership in the multicast group changes. 

8. At time fa, the connection timecharging for userterminal 170expires. Multicast charging unit 144 stops updating 
the entry for user terminal 170 using multicast session p in charging database 146. Multicast charging unit 144 
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communicates with billing server 150 to transfer the charging data for user termini,! 170 using multicast session 
pTom *ar n S database* 146 to billing database 151. Billing unit 151 converts the 

or other form of information for user terminal 170 using multicast session p to the entry of billing database 151 , 
i^iSiSSS total cost of multicast session for user terminal 170. Alternatively, the entry «, chargmg 
database 146 i is transferred periodically to billing server 150. In one embodiment, the entry to chargmg database 
146 appears as follows: 



User 
Identification 


Session Identification 


Connection Time 


Expiration Time of "Joined** 
Status 


21323421 


finnkino 457286529 1453 
172.10.20.212 


(%1 - fel) + (*E2 - fel) 


%2 



HANDOVER 

ro0511 The following examples describe how the system performs charging when a handover occurs from node A 
5, J|! heTrst example the system configuration is as shown in Figure 1B and the handover is from one last 
ho router o anotS UseT^nal 110 needs £ send a new join message to node B and la .disjoin message to node 
A A°ern^ety node B can inform node A of the handover and disjoin user terminal 110 from node KM d 'J. 
comSonentetn node A (group membership management 122. multicast charging unit 124 mult.cast securrty un 
S will fonow the disjoin procedure as described herein. All of the components in node B (group membershp mana 
gement 122? multicast charging unit 124, multicast security unit 124, etc.) will follow the ,o.n procedure as descnbed 

mS" in the second example, the system configuration is as shown in Figure 1B and nodes A and E I are, equipped 
wl independent group m embership management components or link layer group membership management com- 
lenrbut share' he'same muiticast charging unit or charging server. User terminal 110 joins the mult.cast session 
Z node A and later performs a handover from node A to node B. Since node A and node B are both equipped wrth 
Z P membership management or link layer group membership management components, the nodes support chaj- 
L in T hTndover situation if a co.umn is added to the charging entry to identify wh.ch node .s responsib.e for the 
SSlng^T^nod. A, in response to a join request, instructs multicast charging unit 124 to create a charging 
entr? o?use7termina. 110, the ID of node A (e.g., the IP address of node A) 

«nnX resoonsibe for this charging entry". When user terminal 110 performs a handover from node A to node B, user 
tet nail 10 sfndl a join requitto nol B. As a result, node B sends a request for creating charging entry to muljcast 
chZng unit 124 that is shared by node A and node B. Upon receiving such a request multrcast charging un 124 
uodates th^ elevant entry by changing the "node responsiblef orthis charging entry" to node B and updating the jo.ned 
sta'i expfr^ So L i one indicated in the new join message. In addition, multicast charging un.t 24 informs 
node A :*Tnode A is no longer responsib.e for the charging entry associated with user terminal 110. Node a may 
oerform the disjoin procedure described herein to disjoin userterminal 110 from node A 

Pa? For example, before handover, user terminal 110 receives multicast data via node A. The chargmg entry ,s. 



User 
Identification 


Session 
Identification 


Node Responsible 
for this Entry 


Connection Time 


Expiration Time of 
■Joined" Status 


21323421 


finnkino 457286529 
1453 172.10.20.212 


ID of node A 


(%1 -'S1) + ('E2-%1> 




Then user terminal 1' 
management compor 
charging unit 124 to < 
the existing charging 


10 begins to perform the handover. At time f H1 , where < fe 3 , node B 
lent receives the join message join(p, null, f E4 ) from user terminal 110. N 
create a charging entry for userterminal 110. In response, multicast ch< 
entry in the following manner. 


with group membership 
ode B informs multicast 
arging unit 124 modifies 


User 
Identification 


Session 
Identification 


Node Responsible 
for this Entry 


Connection Time 


Expiration Time of 
"Joined" Status 


21323421 


finnkino 457286529 
1453 172.10.20.212 


ID of node B 


(%1 - 'Si) + (*E2 " %l) 
+ ('E4 - <E2> 


%4 



Also,multicastchargingunit124willinformnodeAthatnodeAisnolongerresponsibleforthecharging entry associated 
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with usertermina! 110, Nods A may perform disjoin procedures to disjoin usertermina! 110 from node A. 
SLOTTED CONNECTION TIME 

[0054] Figures 3C and 3D are exemplary timelines for a charging scheme based on connection time that only allows 
a user to join or leave a multicast session at the end of a discrete point in time or time slot. Since the user can only 
join or leave the multicast session at s lotted time intervals (i.e., discrete points in time), the network only needs to 
update to the decryption key at those discrete points in time. Thus : the network can synchronize the disjoin activity of 
multiple users and reduce the number of decryption ke ys delivered. Referring to Figures 1 B and 3C, if user terminal 
170 explicitly requests termination of the multicast session connection, determination of the connection time comprises: 

1 User terminal 1 70 sending a join message to group membership management 1 42 at time f xo . If the join message 
takes the form join(p, r s1 , 2), the user is requesting to join multicast session p, start the connection time charging 
at time t SA , and pay for the service from the start time until time t 3 = [(Zq + m - f s1 ) + (2x m)] where m is the duration 
of a time slot and (q is the start of a time slot. 

2. Multicast security client 173 receiving decryption key 165 from multicast security unit 143 before time f sv The 
multicast network informs user terminal 170 that time f D1 is the deadline for extending the expiration of the con- 
nection to multicast session p. The offset w is defined by the network and represents the time interval between 
the deadline for receiving another join message and the end of a time slot. 

3. At time f s1 , multicast charging unit 144 adds an entry to charging database 1 46 to track connection time charges 
for user terminal 170 using multicast session p. In one embodiment, the entry to charging database 146 appears 
as follows: 



User 
Identification 


Session Identification 


Connection Time 


Expiration Time of "Joined" 
Status 


21323421 


finnkino 457286529 1453 
172.10.20.212 


[(t 0 + rn-t S i) + (2x m)] 


h 



4. From time f s1 until time f 3 , the multicast network is responsible for updating decryption key 1 65 for user terminal 
170 whenever host membership in the multicast group changes. The updates to decryption key 165 occur during 
the offset interval wfor each time slot. During the offset interval w, if the network determines that the status for a 
user will change from "joined" to "disjoined", the network updates decryption key 165. 

5. At time f x1 , where f X i < fci . user terminal 170 extends the stop time by sending a second join message to specify 
a later stop time. If the second join message takes the form join( p, f 3 , 2), the user is requesting to extend the end 
time for the connection to multicast session pfor 2time slots after time f 3 . In one embodiment, the entry to charging 
database 146 appears as follows: 



User 
Identification 


Session Identification 


Connection Time 


Expiration Time of 
"Joined" Status 


21323421 


finnkino 457286529 1453 
172.10.20.212 


[«o + m-r s1 ) + (2x m) + (2 
x m)] 


<5 



The multicast network informs user terminal 170 that time t D2 is the deadline for extendi the expiration of the 
connection to multic ast session p. 

6. From time ^ to time t 5 , the multicast network is responsible for updating decryption key 165 for user terminal 
170 whenever host membership in the multicast group changes. 

7. At time fa, where fa < k)2> user terminal 170 sends a disjoin message that specifies to stop accruing a fee 
when the current time slot expires. If the disjoin message takes the form leave(p, 0), user terminal 170 is requesting 
to leave session p when the current time slot expires. In one embodiment, the entry to chargi ng database 146 
appears as follows: 



User 
Identification 


Session Identification 


Connection Time 


Expiration Time of "Joined" 
Status 


21323421 


finnkino 457286529 1453 
172.10.20.212 


(to+m-f s1 )+(2:<m)4(2 
x m) - (f 5 -t4) 


k 
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10 



15 



20 



25 



30 



8 After time (f 4 - iv) if the network determines that the status for a user will change from "joined" to "d.sjo.neaf , 
the network updates decryption key 165 and continues the multicast session for the user into the next time slot. 

9 At time U collection of connection time charges for user terminal 170 stops. The multicast network «s response 
for updating the "decryption key" for the other group members because user terminal 170 disjoined the multicast 
group Since the collection of connection time charges has stopped, multicas t charging unit 144 closes the entry 
in charging database 146 for user terminal 170 using multicast session p, communicates the charg.ng data to 
billing unit 151 for storage in billing database 152, and deletes the entry in charg.ng database 146. 

r00551 Referring to Figures 1 B and 3D, if termination of the multicast session connection is implied from the passage 
of time, steps 1 through 6 are identical to steps 1 through 6 from the discussion of Figure 3C and determination of the 
connection time comprises: 

1 Userterminal 170 sending a join message to group membership management 142 attime f xo . If the join message 
takes the form joinfp, f s1 , 2), the user is requesting to join multicast session p, start the connection time charging 
at time f s1 , and pay for the service from the start time until time f 3 = [«b + m - f S i) + (2 x m)\ where m is the durat.on 
of a time slot and u is the start of a time slot. 

2 Multicast security client 173 receiving decryption key 165 from multicast security unit 143 before time f s1 . The 
multicast network informs user terminal 170 that time f D1 is the deadline for extending the expiration of the con- 
nection to multicast session p. The offset w is defined by the network and represents the time interval between 
the deadline for receiving anot her join message and the end of a time slot. 

3 At time fe, multicast charging unit 144 adds an entry to charging database 146 to track connection t.me charges 
for user terminal 170 using multicast session p. In one embodiment, the entry to charging databas e 146 appears 
as follows: 



User 
Identification 


Session Identification 


Connection Time 


Expiration Time of "Joined" 
Status 


21323421 


finnkino 457286529 1453 
172.10.20.212 


[(t 0 + m- f S i) + (2X m)] 


h 



35 



40 



A From time fe. until time u, the multicast network is responsible for updating decryption key 165 for userterminal 
170 whenever host membership in the multicast group changes. The updates to decryption key 165 occur during 
the offset interval wfor each time slot. During the offset interval w, if the network determines that the status for a 
user will change from "joined" to "disjoined", the network updates decryption key 1 65. 

5 Attime fv, where f xi <f m , userterminal 170 extends the stop time by sending a second join message to specify 
a later stop time. If the second join message takes the form join(p, f 3 , 2), the user is requesting to extend the end 
time for the connection to multicast session pfor 2time slots after time t 3 . In one embodiment, the entry to charg.ng 
database 146 appears as follows: 



User 
Identification 


Session Identification 


Connection Time 


Expiration Time of 
"Joined" Status 


21323421 


finnkino 457286529 1453 
172.10.20.212 


[(to+m- r sl ) + (2 x m) + (2 
x m)] 


k 



so 



55 



The multicast network informs user terminal 170 that time f^ is the deadline for extending the expiration of the 
connection to multicast session p. 

6. From time (3 to time f 5 , the multicast network is responsible for updating decryption key 165 for userterminal 
170 whenever host membership in the multicast group changes. 

7 After time t D2 if the network determines that the status for a user will change from "joined to disjoined , the 
network updates decryption key 165 and continues the multicast session for the user into the next time slot. 

8 At time U collection of connection time charges for userterminal 170 stops. The multicast network is responsible 
for updating the "decryption key" for the other group members because user terminal 170 disjoined the multicast 
group Since the collection of connection time charges has stopped, multicast charging unit 144 closes the entry 
in charging database 146 for user terminal 170 using multicast session p, communicates the charging data to 
billing unit 151 for storage in billing database 152, and deletes the entry in charging database 146. Alternatively, 
multicast charging unit 144 transfers the entry directly to billing server 150. In another embodiment, the entry to 
charging database 1 46 appears as follows: 
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User 
Identification 


Session Identification 


Connection Time 


Expiration Time of 
"Joined" Status 


21323421 


finnkino 457286529 1453 
172.10.20.212 


U 0 + m-? s1 ) + (2xm)+(2x 
m) 





Data Volume Based Charging 



[0056] A charging scheme based on the volume of data calculates a fee for a service from the volume of data that 
a user receive s from the service. For example, if a network operator determines that the rate for using a video service 
is $0.25 for each Megabyte of data received, a user connecting to the video service to view a movie consisting of 25 
Megabytes of data accrues a fee of $6.25. In a multicast network, a charging scheme based on the volume of data is 
most beneficial when the data rate varies. Similar to the charging scheme based on connection time discussed above, 
the connectivity and security is managed on time basis, however, determination of charge requires accounting for the 
number of bytes transferred during the connection time. 

[0057] Figures 4A and 4B are exemplary timelines for a charging scheme based on data volume that only allows a 
user to join or leave a multicast session at the end of a discrete point in time or time slot. Referring to Figures 1 B and 
4A, if user terminal 170 explicitly requests termination of the multicast session connection, determination of the data 
volume comprises: 

1 . Data volume meter 145 examining IP multicast data packets and maintaining a tally of the number of bytes of 
data received, for a given destination address and multicast session. Data volume meter 145 can either be co 
-located with multicast charging unit 144 or located on an upper layer of the multicast tree (e.g., on the gateway 
router where the multicast data enters the multicast network). In one embodiment, each last hop router may include 
a meter for measuring the multicast session routed to the last hop router. In another embod iment, the meter can 
be distributed across-several access routers in the multicast network. 

2. User terminal 1 70 sending a join message to group membership management 1 42 at time f x0 . If the join message 
takes the form join(p, f s1 , 2), the user is requesting to join multicast session p, start the connection time charging 
at time f s1 , and pay for the service from the start time until time f 3 = [(f 0 + m - f s1 ) + (2 x m)] where m is the duration 
of a time slot and % is the start of a time slot. Calculation of the fee depends on the volume of data received by a 
given destination and multicast session between time f s1 and f 3 . 

3. Multicast security client 173 receiving decryption key 165 from multicast security unit 143 before time f s1 . The 
multicast network informs user terminal 170 that time r D1 is the deadline for sending another join message. The 
offset w is defined by the network and represents the time interval between the deadline for receiving another join 
message and the end of a time slot. 

4. At time f s1 , data volume meter 145 signals multicast charging unit 144 to add an entry to charging database 
146 to store the data volume start value, for user terminal 170 using multicast session p. In one embodiment, 
the entry to charging database 146 appears as follows: 



User 
Identification 


Session Identification 


Data Volume on Meter 


Expiration Time of "Joined 0 
Status 


Start 
Value 


End 
Value 


21323421 


finnkino 457286529 1453 
172.10.20.212 




Null 


k 



5. From time *si until time ^, the multicast network is responsible for updating decryption key 165 for user terminal 
170 whenever host membership in the multicast group changes. The updates to decryption key 1 65 occur during 
the offset interval tv for each time slot. During the offset interval w, if the network determines that the status for a 
user will change from "joined" to "disjoined", the network updates decryption key 165. 

6. At time f x1 , where J X1 < f D1 , user terminal 170 extends the stop time by sending a second join message to specify 
a later stop time. If the second join message takes the form join(p, / 3 , 2), the user is requesting to extend the end 
time for the connection to multicast session p for 2 time slots after time f 3 . In one embodiment, the entry to charging 
database 146 appears as follows: 
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User 
Identification 


Session Identification 


Data Volume on Meter 


Expiration Time of "Joined" 
Status 


Start 
Value 


End 
Value 


21323421 


finnkino 457286529 1 453 
172.10.20.212 




Null 





The multicast network informs user terminal 170 that time fa is the deadline for extending the expiration of the 
connection to multicast session p. 

7. From time f 3 to time f 5 . the multicast network is responsible for updating decryption key 165 for user term.nal 
170 whenever host membership in the multicast group changes. 

8 At time f x2 where t X2 < fa, user terminal 170 sends a disjoin message that specifies to stop accruing a fee 
when the current time slot expires. If the disjoin messagetakes the form leave(p, 0), user terminal 170 .s requesting 
to leave session p when the current time slot expires. In one embodiment, the entry to charging database 146 
appears as follows 



User 
Identification 


Session Identification 


Data Volume on Meter 


Expiration Time of "Joined" 
Status 


Value 
Start 


End 
Value 


21323421 


finnkino 457286529 1453 
172.10.20.212 




Null 


k 



9 After time (f 4 - w).tf the network determines that the status for a user will change from "joined" to "disjoined", 
the network updates decryption key 165 and continues the multicast session for the user into the next time slot. 

10 At time f 4 collection of the data volume charges for user terminal 170 stops. Data volume meter 145 commu- 
nicates the data volume end value, V 2 , for user terminal 170 using multicast session p to multicast charging unit 
144. Multicast charging unit 144 updates the entry to charging database 146. In one embodiment, the entry to 
charging database 146 appears as follows: 



User 
Identification 


Session Identification 


Data Volume on Meter 


Expiration Timeof "Joined" 
Status 


Start 
Value 


End 
Value 


21323421 


finnkino 457286529 1453 
172.10.20.212 


^1 


v 2 


'4 



Since the collection of data volume charges has stopped, multicast charging unit 144 closes the entry in charging 
database 146 for user terminal 170 using multicast session p, communicates the charging data to b illing unit 151 
for storage in billing database 152, and deletes the entry in charging database 146. Since the charging data is 
summarized the total volume of data for user terminal 170 using multicast session p is (V 2 - VJ. In another em- 
bodiment, data volume meter 145 communicates the charging data to billing server 150 directly, without storing 
the charging data in charging database 146. 

[0058] Referring to Figures 1 B and 4B, if termination of the multicast session connection is implied from the passage 
of t ime, steps 1 through 7 are identical to steps 1 through 7 from the discussion of Figure 4A and determination of the 
data volume comprises: 

1 Data volume meter 145 examining IP multicast data packets and maintaining a tally of the number of bytes of 
data rece ived, for a given destination address and multicast session. Data volume meter 145 can either be co 
-located with multicast charging unit 144 or located on an upper layer of the multicast tree (e.g., on the gateway 
router where the multicast data enters the multicast network). In one embodiment, each last hop router may include 
a meter for measuring the multicast session routed to the last hop router. In another embodiment, the meter can 
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be distributed across several access routers in the multicast netvvor k. 

2. User terminal 1 70 sending a join message to group membership management 1 42 at time f xo . If the join message 
takes the form join(p, J S1 . 2). the user is requesting to join multicast session p, start the connection time charging 
at time r s1 , and pay for the service from the start time until time t 2 = [(f 0 + m - / S1 ) + (2 x m)] where m is the duration 
of a time slot and is the start of a time slot. Calculation of the fee depends on the volume of data received by a 
given destination and multicast sessi on between time / S1 and t 3 . 

3. Multicast security client 173 receiving decryption key 165 from multicast security unit 143 before time f sv The 
multicast network informs user terminal 170 that time f D1 is the deadline for sending another join message. The o 
ffset wis defined by the network and represents the time interval between the deadline for receiving another join 
message and the end of a time slot. 

4. At time f s1 , data volume meter 145 signals multicast charging unit 144 to add an entry to charging database 
146 to store the data volume start value, V 1( for user terminal 170 using multicast session p. In one embodiment, 
the entry to charging database 146 appears as follows: 



User 
Identification 


Session Identification 


Data Volume on Meter 


Expiration Time of "Joined" 
Status 


Start 
Value 


End 
Value 


21323421 


finnkino 457286529 1453 
172.10.20.212 




Null 


'3 



5. From time f s1 until time f 3 , the multicast network is responsible tor updating decryption key 165 for user terminal 
170 whenever host membership in the multicast group changes. The updates to decryption key 165 occur during 
the offset interval wfor each time slot. During the offset interval w, if the network determines that the status for a 
user will change from "joined" to "disjoined", the network up dates decryption key 165. 

6. At time f x1 , where f x1 < t ov userterminal170 extends the stop time by sending a second join message to specify 
a later stop time. If the second join message takes the form join( p, f 3 , 2), the user is requesting to extend the e 
nd time for the connection to multicast session p for 2 time slots after time fe. In one embodiment, the entry to 
charging database 146 appears as follows: 



User 
Identification 


Session Identification 


Data Volume on Meter 


Expiration Time of "Joined' 1 
Status 


Start 
Value 


End 
Value 


\ 21323421 


finnkino 457286529 1453 
172.10.20.212 




Null 


k 



The multicast network informs user terminal 170 that time t oz is the deadline for extending the expiration of the 
connection to multicast session p. 

7. From time t 3 to time f 5 . the multicast network is responsible for updating decryption key 165 for user terminal 
170 whenever host membership in the multicast group changes. 

8. After time fc 2 , if the network determines that the status for a user will change from "joined" to "disjoined", the 
network updates decryption key 165 and continues the multicast session for the user into the next time slot. 

9. At time ^ collection of the data volume charges for user terminal 170 stops. Data volume meter 145 commu- 
nicates the data volume en d value, V 3 , for user terminal 1 70 using multicast session p to multicast charging unit 
144. Multicast charging unit 144 updates the entry to charging database 146. In one embodiment, the entry to 
charging database 146 appears as follows: 



User 
Identification 


Session Identification 


Data Volume on Meter 


Expiration Time of "Joined" 
Status 


Start 
Value 


End 
Value 


21323421 


finnkino 457286529 1453 
172.10.20.212 




v 3 


<4 
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Since the collection of data volume charges has stopped, multicast charging unit 144 closes the entry in charging 
database 146 for user terminal 170 using multicast session p, communicates the charging data to billing unit 151 
for storage in billing database 152. and deletes the entry in charging database 146. Since the charging data is s 
ummarized the total volume of data for user terminal 170 using multicast session p is < V 3 - V,). In another em- 
bodiment, data volume meter 145 communicates the charging data to billing server 150 directly, without storing 
the charging data in charging dat abase 146. 

[0059] Although the embodiments disclosed herein describe a fully functioning system, method, and computer pro- 
gram product for calculating a cost of receiving multicast data from a multicast session, the reader should understand 
that other equivalent e mbodiments exist. Since numerous modifications and variations will occur to those who review 
this disclosure, the system, method, and computer program product for calculating a cost of receiving multicast data 
from a multicast session is not limited to the exact construction and operation illustrated and disclosed herein. Accord- 
ingly, this disclosure intends all suitable modifications and equivalents to fall within the scope of the claims. 

Claims 

1 A method of calculating a cost of receiving multicast data from a multicast session, a multicast network (105) 
including at least one multicast service, each multicast service including at least one multicast session, comprising: 

receiving a request (117) to establish a connection to the multicast session, th e request including a start time 
for the connection and an end time for the connection; 

storing the start time for the connection and the end time for the connection; and 
after termination of the connection, calculating the cost of receiving the multicast data. 

2. A method according to claim 1 , further comprising: 

receiving a subsequent request to extend the connection, the subsequent request specifying a new end time 

for the connection; and 

storing the new end time for the connection. 

3. A method according to claim 1 , further comprising: 

receiving a subsequent request to terminate the connection the subsequent request specifying a new end 
time that precedes the end time for the connection; and 
storing the new end time for the connection. 

4. A method according to any preceding claim, wherein the storing of the start time for the connection and the end 
time for the connection is to a database. 

5. A method according to any preceding claim, wherein the calculating of the cost further comprises: 

computing a charge for receiving the multicast data; 
storing the charge; and 

computing the cost by multiplying the charge by a fee for the multicast service associated with the multicast 
session. 

6. A method according to claim 5, wherein the computing of the cha rge further comprises: 

computing an elapsed connection time by subtracting the start time for the connection from the end time for 
the connection. 

7. A method according to claim 5, wherein the computing of the charge further comprises: 

computing a volume of data received over the connection from the start time for the connection to the end 
time for the connection. 

8. A method according to claim 5, wherein the storing of the charge is to a database. 
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9. A computer program product comprising: 

a computer readable medium; and 

program code in said computer readable medium; 

said program code for performing the method according to any preceding claim. 

10. A system for calculating a cost of receiving multicast data from a multicast session, a multicast network (105) 
including at least one multicast service, each multicast service including at least one multicast session, comprising: 

a memory device; and 

a processor disposed in communication with the memory device, the processor configured to: 

receive a reque st (117) to establish a connection to the multicast session, the request including a start 

time for the connection and an end time for the connection; 

store the start time for the connection and the end time for the connection; and 

alter termination of the connection, calculate the cost of receiving the multicast data. 

11. A system for calculating a cost of receiving multicast data from a multicast session, a multicast network (105) 
including at tens! one multicast service, each multicast service includin g at least one multicast session, comprising: 

a collection dcv»ce comprising 

a collection memory device: and 

a collection processor disposed in communication with the collection memory device, the collection proc- 
essor configured to: 

receive a request (1 1 7) to establish a connection to the multicast session, the request including a start 

time for the connection and an end time for the connection; 

store the start time for the connection and the end time for the connection; and 

after termination of the connec tion, calculate the cost of receiving the multicast data; and 

an interface device comprising: 

an interface memory device; and 

an interface processor disposed in communication with the interface memory device, the interface proc- 
essor configured to: 

configure the collection device; and 

display the cost of receiving the multicast data. 

12. A system according to claim 10 or 11 , wherein the processor or the collection processor is further configured to: 

receive a subsequent request to extend the connection, the subsequent request specifying a new end time 

for the connection; and 

store the new end time for the connection. 

13. A system according to claim 10 or 11 , wherein the processor or the collection processor is further configured to: 

receive a subsequent re quest to terminate the connection, the subsequent request specifying a new end time 
that precedes the end time for the connection; and 
store the new end time for the connection. 

14. A system according to any one of claims 10 to 13, wherein the processor or collection processor stores the start 
time for the connection and the end time for the connection to a database. 

15. A system according to any one of claims 10 to 13, wherein to calculate the cost, the processor or the collection 
processor is further configured to: 
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compute a charge for receiving the multicast data; 
store the charge; and 

compute the cost by multiplying the charge by a fee for the multicast service associated with the multicast 
session. 

16. A system according to claim 15, wherein to co mpute the charge, the processor or the collection processor is 
further configured to: 

compute an elapsed connection time by subtracting the start time for the connection from the end time for the 
connection. 

17. A system according to claim 1 5, wherein to compute the charge, the processor or the collection processor is further 
configured to: 

compute a volume of data received over the connection from the start time for the connection to the end time 
lor the connection. 

18. A system according to any one of claims claim 15 to 1 7, wherein the processor or the collection processor stores 
tne charge to a database. 

19. A method computer program product or system according to any preceding claim, wherein time is divided into 
evenly spaced time slots ; and where in the start time for the connection the end time for the connection can only 
occur at the end of a time slot. 

20. A method computer program product or system according to claim 19, wherein the end time for the connection 
in the request is specified as a discrete number of time slots. 

21. An apparatus for calculating a cost of receiving multicast data from a multicast session, a multicast network in- 
cluding at least one multicast service, each multicast service including at least one multicast session, comprising: 

a computer readable medium; 

program code in said computer readable medium for sending a request to establish a connection to the mul- 
ticast session, the request including a start time for the connection and an end time for the connection; 
program code in said computer readable medium for sending a first subsequent request after the request, the 
first subsequent request including a new end time for the connection, the new end time being later than the 
end time: and 

program code in said computer re adable medium for sending a second subsequent request after the first 
subsequent request, the second subsequent request including an earlier end time for the connection, the 
earlier end time after the end time and before the new end time. 

22. The apparatus of claim 21 , further comprising: 

program code in said computer readable medium for determining a request time interval; 

wherein sending the request, sending the first subsequent request, and sending the second subsequent 
request only occur at a time tha t is a multiple of the request time interval from the start time. 
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Figure 2A 
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Figure 2B 
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Figure 2C 
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Figure 2D 
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